In modern computing systems, most applications require an operating system (OS) to execute. In recent years, even applications such as anti-virus utilities, disk defragmentation utilities, undelete utilities, data recovery utilities, hardware diagnostic utilities, and other hardware repair utilities are usually executed within an OS environment, even if they perform such tasks traditionally thought of as “low level”, e.g. operating on or near the hardware level, usually unmediated by an interface.
It is necessary or desirable to execute some applications outside an OS environment. One such example occurs when the OS itself becomes infected with a virus. In such a case, an anti-virus program generally cannot remove the virus and repair the system without endangering system stability or corrupting the OS files. This is especially true if the infected files are crucial to the operation of the OS, or if the infected files are currently resident in main memory.
If a user is confronted with such an error, her only option may be to restart the system and boot the system from an external source, such as a removable disk, and attempt to correct the problem. Usually, these removable disks contain a second OS of only minimal functionality, and often do not contain the very utility needed to fix the problem. Furthermore, a program that detects a problem while running in an OS environment may not directly pass information to a utility running from a boot disk or similar device. Thus, the boot disk may have to initiate the error detection and recovery processes from scratch, wasting valuable time.